Preventing interference between subsystem blocks at a design time

ABSTRACT

A method of preventing interference between subsystem blocks includes obtaining an integrity level for a first subsystem block, obtaining an integrity level for a second subsystem block, assigning an integrity level property to at least one input port of the first block, the integrity level property assigned to the input port of the first block being based on the integrity level defined for the first block, and assigning an integrity level property to at least one output port of the second block, the integrity level property assigned to the output port of the second block being based on the integrity level defined for the second block. The method further includes evaluating the integrity level property of at least one input/output pair to determine whether an inappropriate connection exists, and performing a first action when an inappropriate connection exists, or performing a second action when an appropriate connection exists.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/729,982, filed Dec. 28, 2012, the entire contents of which isincorporated by reference herein.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 illustrates an example of an integrity level partial order set.

FIG. 2 illustrates a first example of a model according to theinvention.

FIG. 3 illustrates a second example of a model according to theinvention.

FIG. 4 shows an exemplary computer system suitable for supporting thedescribed embodiments of the invention.

FIG. 5 shows an example of a Technical Computing Environment (TCE).

FIG. 6 shows one of the described embodiments.

FIG. 7 shows another of the described embodiments.

DETAILED DESCRIPTION

Graphical modeling tools (e.g., MathWorks Simulink environment, amongothers—can be referred to generally as modeling tools) may be used tomodel and simulate the behavior of a system or collection of systems.Such modeling tools may represent a system or a collection of systems asan interconnected set of subsystem blocks. A subsystem block may be acollection of components constructed and arranged to perform a complexfunction, or a subsystem block may be a single basic block (e.g., anamplifier or resistor). Each subsystem block may include certaininterfaces, such as inports (input ports) and outports (output ports),through which the subsystem blocks are interconnected. The subsystemblocks may be arranged in a hierarchical structure (e.g., such that oneof the collection of components represents a subsystem block itself), anon-hierarchical structure, or a combination of hierarchical andnon-hierarchical structures.

The interconnections between subsystem blocks in a model facilitatecommunication between the subsystem blocks, i.e., they enable asubsystem block to influence one or more other subsystem blocks. Theinfluence of one block to other blocks may be part of the system designand therefore intentional. As the system model becomes more complex, thelikelihood of unintentional influence of one subsystem block on anothersubsystem block increases. Such unintended influence can be referred toas subsystem interference.

The following example illustrates why it is important to reduce oreliminate interference between subsystem blocks. Consider the model of acommercial airliner. Such a model may include many interconnectedsubsystems. Two of those subsystems may include the air conditioningsubsystem and the engine subsystem. A malfunction in the airconditioning subsystem may be an inconvenience, while a malfunction inthe engine subsystem would likely constitute an emergency.

In this example, it is important that the state of the air conditioningsubsystem does not unintentionally influence the engine subsystem. Inother words, a malfunction of an non-critical subsystem should not beallowed to precipitate a malfunction of a mission-critical subsystem.

A modeling tool may describe the commercial airliner as aninterconnection of a thousand or more subsystems, presented as a complexmodeling tool (e.g., Simulink) block diagram. The air conditionersubsystem and the engine subsystem may be just a small percentage of themany subsystems in the airliner design. Deployable code may be directlyautomatically and/or generated from this block diagram and laterdeployed to the computers on board the actual airliner.

The described embodiments present a technique for identifying if theabove-mentioned subsystem interference occurs. Identifying that theabove-mentioned subsystem interference does not occur in the model mayensure that the above-mentioned subsystem interference will not occurand thus in the generated code.

The described embodiments apply the notion of integrity level tosubsystem blocks and their inports and outports, and may utilize anassociated type-checking system to enforce rules based on the integritylevels. The rules may help reduce the likelihood of interference betweensubsystem blocks. The described embodiments may enable modeling tools todetect and prevent interference between subsystem blocks at design time,to facilitate high integrity system modeling.

The integrity level of a subsystem may describe the criticality of thesubsystem, i.e., how important the subsystem is to the expectedperformance of the overall system of which the subsystem is a part. Insome embodiments, a designer can associate an integrity level to asubsystem block or to an inport or outport (or combinations thereof) ofthe subsystem block by assigning an integrity level property to thesubsystem block, inport or outport. In other embodiments thetype-checking system can assign an integrity level property to asubsystem block inport or outport based on the integrity level that hasbeen defined for or associated with the associated subsystem block. Insome embodiments, the integrity level property is characterized bydiscrete values, while in other embodiments the integrity level ischaracterized by a selection from a range defining a continuum ofintegrity levels.

In an embodiment, integrity levels may be specified or stipulated bysystem or subsystem requirements. For example, a portion of arequirements specification for a subsystem may include predefinedintegrity levels for one or more elements of that subsystem. When thesubsystem is modeled by the graphical modeling tool, a designer mayextract information (e.g., manually or automatically from a requirementsspecification for use in creating/designing the model. During thedesign, the designer may transfer the integrity levels from therequirements specification to the model either during or following thedesign process.

The integrity levels specified for subsystem components may relate to areal time system constraint, such as allowed latency for particularcomponents. For example, code generated from models constructedaccording to the described embodiments may be executed in a particularorder and/or with a different priority, the order being relative to theassociated integrity level. Code associated with lower integrity levelsmay be treated as less critical, providing greater flexibility as towhen that code executes relative to when more critical (i.e., higherintegrity) code executes.

The non-interference discipline enforced by the type system of thedescribed embodiments may result in more reliable deployed code. Forexample, suppose a pair of subsystems are constructed according to thedescribed embodiments such that neither subsystem interferes with theother. Code deployed based on those subsystems is less likely tointerfere with each other than without using such non-interferencediscipline, and thus can potentially be executed in parallel.

In one or more of the described embodiments, a designer can associate anintegrity level with any subsystem block. The designer can likewiseassociate an integrity level with the inports and the outports of thesubsystem. In the described embodiment, a rule associated with theintegrity levels is as follows: the computational behavior of a firstsubsystem can only be influenced, directly or indirectly, by a secondsubsystem having an integrity level at least as high as the integritylevel of the first subsystem.

An integrity level l may come from a partial order set that the user candefine, and the only significant information that the user should supplyis the level's order with respect to another level. For example, theorder may be similar to the subclass relationship in an OO(Object-Oriented) design. For example, l₁≦l₂ stands for level l₂ beingat least as high as level l₁. Since it is a partial order set, theelements obey the reflexivity, antisymmetry, and transitivity rules,i.e., for all levels l, m, n, we have:

-   -   l≦l(reflexivity)    -   if 1≦m and m≦l then, l=m(antisymmetry)    -   if l≦m and m≦n then, l≦n(transitivity)

FIG. 1 is illustrates an example of an integrity level partial order setthat the user could define (

and ⊥ represent the top and the bottom of all the integrity levels,respectively).

FIG. 1 demonstrates defined integrity levels having the followingrelationships:

-   -   ⊥≦l₅≦l₆≦        ,    -   ⊥≦l₄≦l₃≦l₁≦    -   ⊥≦l₄≦l₃≦l₂≦

In partial ordered sets, not all elements have defined relationships.For example, in FIG. 1, no relationship is defined between l₁ and l₂, orbetween l₆ and l₄.

The disclosed type-checking system is immediately useful to enforceother similar but more subtle non-interference disciplines in modelingtools. Examples of those interferences include, but are not limited to,sample time, data type, and signal dimension type propagations betweensubsystems. For example, if one were to enforce a discipline such thatthe sample time of subsystem A should have an independent sample time ofSubsystem B and vice versa, the designer could choose to label A withintegrity level l and to label B with integrity level m such that l

m

m

l. Alternatively, or additionally, the designer could choose to labelthe sample time property of subsystem A with integrity level l and tolabel the sample time property of subsystem B with integrity level msuch that l

m

m

l.

In the described embodiments, an integrity level may be labeled on asubsystem block, the subsystem block inports, the subsystem blockoutports, a connection from or to the subsystem block, the subsystemblock properties, the subsystem block inport properties, the subsystemblock outport properties, or any combination thereof. Such labeling maybe accomplished by assigning an integrity level property to the relevantsubsystem block or the relevant subsystem component and/or a connection,as described above.

As an example regarding architectural patterns, a component having anintegrity level of SIL4 in an hierarchical system may be realized byassigning SIL4 to all the elements in the hierarchy that are beneath theSIL4 component. However, this approach may not be cost and/or resourceeffective. Alternatively this behavior can be realized by decomposingthe SIL4 component into two parallel and independent SIL3 componentsthat are arbitraged by some voting component. Yet alternatively, thesame SIL4 may be realized by decomposing it in less critical SIL2component that implements the algorithm and a SIL4 component that checkswhether SIL2 component works properly. In this case two differentarchitectural (or decomposition) patterns (two parallel channels plusvoter; algorithm component and independent supervision component) arepresent that allow to achieve a higher integrity level by combiningcomponents with lower integrity levels in some specific patterns. Notethat patterns and integrity levels are just examples that may bedifferent for different standards. Some safety standards refer to theseconcepts as SIL arithmetic or ASIL decomposition.

Based on knowledge about such architectural patterns and on informationthat designates certain components as elements of such patterns, thetype-checking system may calculate different integrity levels ascompared to a type-checking system that does not have information aboutthose patterns. The different integrity levels as calculated by thetype-checking system that has information about those patterns may bebetter, more accurate, more useful, etc. Based on a given modelstructure the type-checking system may also propose architecturalmodifications to increase and/or decrease the integrity level of certaincomponents.

As used herein, the symbol L denotes the integrity level that is markedby a designer on a subsystem block, any of its inports or outports, orany of the connections to or from a subsystem block. Some embodimentsreduce or eliminate interference between subsystem blocks by enforcingthe discipline that the computational behavior of a first subsystemblock can only be influenced by another subsystem block the integritylevel of which is higher or equal than the integrity level of the firstsubsystem block. This discipline may be notationally set forth with thetwo type-checking rules as follows. Given a subsystem block S:

∀_(i)ε inports(S),L(S)≦L(i)  [A1]

∀_(o)ε outports(S),L(o)≦L(S)  [A2]

These two type-checking rules ensure that: (1) the integrity levelmarked for a subsystem block is not higher than the integrity level ofany of its inports, and (2) the integrity level for a subsystem block isat least as high as the highest integrity level marked for all of itsoutports.

The discipline described above may be further enforced by implementingthe following outport to inport connection type-checking rule: if theoutport (O) and the inport (i) belong to a different subsystem block,then:

O→i if and only if L(i)≦L(O)  [A3]

where O→i means that an outport can connect to an inport. This typechecking rule makes sure that an outport can only influence an inportwhose integrity level is not higher than the outport.

In some embodiments, the integrity level may be inferred rather thanassigned. Inferring integrity levels means that unspecified integritylevels (which may include, for example, specified yet default integritylevels) of connections, inports, outports and/or subsystem blocks may bedetermined through the equality/inequality system of [A1], [A2] and [A3]described in the preceding paragraphs, provided that a solution for theequation system exists. If integrity assignments corresponding to asolution cannot be found, then an invalid connection in the blockdiagram is must exist and a type checking error may be reported.Propagation of integrity levels from associated subsystem blocks is anexample of a technique for inferring an integrity level. Propagation maybe upstream (e.g., following the input to output direction of aconnection), downstream (e.g., following the output to input directionof a connection), or a combination.

In some embodiments, inferring the integrity level of an unassignedinport or outport may change the integrity level of a port connected tothe unassigned port. For example, if the integrity level of theunassigned inport or outport is inferred because of the unassignedinport or outport being related to a lower-level subsystem block, thisinference may cause the integrity level of the port connected to theunassigned port to increase. Re-wiring a connection between aninport/outport is another condition that may cause the integrity levelto increase. The integrity levels may need to be changed so that theequation system mentioned above can be satisfied. The integrity levelchange may be determined based on one or more redundancy requirements.Such redundancy requirements may include inference based on a series ofrequirements linked to one another, or inference based on informationregarding architectural patterns of the modeled system, or explicitindication by a designer or other user.

If a block diagram satisfies the type-checking rules set forth above,given any two subsystems blocks A and B, if L(A)≦L(B) and L(A)≠L(B),then subsystem block A will not influence the functionality of subsystemblock B because no output of subsystem block A will (directly orindirectly, that is, with output of subsystem block A driving input ofsubsystem block B via other blocks) drive an input of subsystem block B.

One of the type-checking rules may be restated as requiring that areceiving subsystem block is not permitted to accept information from atransmitting subsystem block that has an integrity level property thatis lower than the integrity level property of the receiving subsystemblock. Another of the type-checking rules may be restated as requiringthat a transmitting subsystem block is not permitted to provideinformation to a receiving subsystem block that has an integrity levelthat is higher than the integrity level of the transmitting subsystemblock.

The type-checking system of the described embodiments may implement thetype-checking rules described above by evaluating the integrity levelproperties of an inport/outport pair to determine whether the connectionis appropriate or inappropriate with respect to the above-mentionedrules. The connection may be appropriate if the above-mentioned rulesare satisfied, and the connection may be inappropriate if theabove-mentioned rules are not satisfied.

If the connection is determined to be inappropriate, then in someembodiments the type-checking system performs an action to address theinappropriate connection. For example, the type-checking system maysever the connection of the input/output pair. As another example, thetype-checking system may present an indication that identifies theconnection of the input/output pair as being inappropriate.

In an embodiment, the evaluation of the type-checking rules may occur asthe designer creates the connections between the subsystem blocks in themodel, so that the designer can receive an indication of whether theconnection is appropriate or inappropriate during the design process. Inother embodiments, the evaluation of the type-checking rules may occurafter the designer as completed all of the connections, or aftercompleting a predetermined number of connections. The predeterminednumber may be a value selected arbitrarily by the user or determined bythe system (e.g., based on system parameters such as available memory,processing time, number of available computing cores, etc.), or it maybe based on items such as the size of the model, the number of inportsand outports, and the like. In yet other embodiments, the evaluation ofthe type-checking rules may be invoked based on a user command.

Described embodiments may be demonstrated with the example shown in FIG.2. This example, based on the commercial airline model described above,shows an erroneous connection 206 from the Humidity outport 204 of theAir Conditioner subsystem 202 to the Speed import 208 of the EngineControl subsystem block 210.

In this example, the designer labels each of the relevant subsystemblocks with a particular integrity level. For example, the designer maylabel the Air Conditioner1 subsystem block with integrity level L andthe Engine Control subsystem block with integrity level H, where L≦H.

In an embodiment, the type-checking system automatically infers theintegrity levels for the inports and outports, based on the subsystemintegrity levels L and H, and from the typing rules set forth herein. Inthis exemplary case, there may be only one possibility for the outportsof the Air Conditioner1 subsystem block and the inports of the EngineControl subsystem block, as illustrated in FIG. 3. The type-checkingsystem determines that the line 206 connecting the two subsystems isillegal with respect to the type-checking rules. In an embodiment, thetype-checking system reports the illegal connection to the user. Inanother embodiment, the type-checking system automatically severs 302the illegal connection to eliminate this case of subsystem interference.In yet another embodiment, the type-checking system may report to theuser the lowest integrity level that could be assigned to the AirConditioner1 subsystem block while still meeting the type-checkingrules. Further, another embodiment may provide the user with an optionto automatically lower the integrity level of the Engine Controlsubsystem block so that it matches (or is otherwise compatible with) theintegrity level of the Air Conditioner1 subsystem block. Yet further,another embodiment may provide the user with an option to automaticallyincrease the integrity level of the Air Conditioner1 subsystem (e.g.,based on an architectural pattern) so that it matches (or is otherwisecompatible with) the integrity level of the Engine Control subsystem. Inyet a further embodiment, during editing, the user may not be able tocreate a connection between the Air Conditioner1 subsystem block and theEngine Control subsystem block.

Embodiments described herein can be implemented on various types ofcomputer systems (e.g., desktop, laptop or notebook PC, mobile handheldcomputing system, workstation or other particular machine). Describedembodiments may be implemented in a computer program product that may benon-transitory and may be tangibly embodied in a machine-readablestorage medium for execution by the computer system. Methods ofdescribed embodiments may be performed by a computer system executing aprogram to perform functions, described herein, by for example,operating on input data and/or generating output.

An exemplary computer system 402 is shown in FIG. 4. Referring to FIG.4, computer system 402 may include a processor 404, an informationstorage medium 406, and a user interface 408. These components may becontained within a typical desktop, laptop or mobile form factorhousing, or they may be integrated into a single component such as amulti-chip module or ASIC (application specific integrated circuit).

Suitable processors 404 may include, for example, both general andspecial purpose microprocessors. Generally, the processor 404 receivesinstructions and data from a read-only memory (ROM) and/or a randomaccess memory (RAM) through a CPU bus. The processor 404 may alsoreceive programs and data from a storage medium 406, such as, forexample, an internal disk operating through a mass storage interface, ora removable disk operating through an I/O interface. Instructions 407for executing the described embodiments may be stored on the storagemedium.

Information storage media 406 suitable for tangibly embodying computerprogram instructions for implementing the described embodiments mayinclude various forms of volatile memory and/or non-volatile memory,including but not limited to, semiconductor memory devices, such asEPROM, EEPROM, and flash memory devices, and magnetic disks, such asinternal hard disks and removable disks, magneto-optical disks, andCD-ROM disks. The information storage medium 406 may also store anoperating system (“OS”), such as Windows or Linux, which the processormay execute to provide, for example, a supervisory working environmentfor the user to execute and control, for example, one or moreembodiments of the invention.

The user interface 408 may include a keyboard, mouse, stylus,microphone, camera, accelerometer, gyroscope, trackball, touch-sensitivescreen, or other input device. These elements are typically found in aconventional desktop computer as well as other computers andworkstations suitable for executing computer programs implementingmethods described herein (e.g., smartphones, tablet computers, notebookcomputers, etc.). The computer system 402 may also be used inconjunction with a display device for providing a GUI. The displaydevice may include an output device that may be capable of producingcolor or gray scale pixels on paper, film, display screen, or otheroutput medium.

The touch-sensitive screen described above may be used to effect amulti-point input interface. For example, the user may sequentially orsimultaneously select items in the GUI using two or more fingers.

The graphical modeling tools of the described embodiments may provide(and operate within) what is generally known as a Technical ComputingEnvironment (TCE). A TCE is a computing environment that can, forexample, perform numerical linear algebraic calculations, solve ordinarydifferential equations, analyze data, and visualize solutions to complexmathematical formulas by generating graphs or other images. The TCE canenable a user to perform tasks related to disciplines such asmathematics, science, engineering, medicine, business, biology andfinance, to name a few. The TCE may include a programming language(e.g., the MATLAB language) to express problems and/or solutions inmathematical notations. The programming language may be suitable fornon-professional programmers and may provide graphical tools for use increating plots, surfaces, images, volumetric representations, or otherrepresentations. The TCE may provide these routines and/or tools usingtoolboxes (e.g., toolboxes for signal processing, image processing, dataplotting, parallel processing, etc.). The TCE may also provide theseroutines in other ways, such as, for example, via a library, local orremote database (e.g., a database operating in a computing cloud),remote procedure calls (RPCs), and/or an application programminginterface (API). Embodiments of the TCE may be configured to improveruntime performance when performing computing operations. For example,TCE may include a just-in-time (JIT) compiler in an exemplaryembodiment.

The TCE may perform matrix and/or vector computations for use in dataanalysis, data visualization, application development, simulation,modeling, and/or algorithm development. Fields of use may include, butare not limited to, statistics, image processing, signal processing,control design, life sciences modeling, financial modeling, discreteevent analysis and/or design, and state-based analysis and/or design.

Examples of TCEs and/or TCE-like applications that may be adapted toimplement one or more embodiments of the invention may include, but arenot limited to applications that implement languages such as the MATLAB®environment available from The MathWorks, Inc.; GNU Octave from the GNUProject; Mathematica from Wolfram Research, Inc.; Mathcad from MathsoftEngineering & Education Inc.; Maple from Maplesoft; Scilab from TheFrench Institution for Research in Computer Science and Control (INRIA);Virtuoso from Cadence; or Modelica or Dymola from Dassault Systèmes.

In another example embodiment, the TCE may be implemented in agraphically-based modeling environment using products such as, but notlimited to, Simulink®, Stateflow®, SimEvents®, Simscape™, etc., by TheMathWorks, Incorporated; VisSim by Visual Solutions; LabView® byNational Instruments; Dymola by Dynasim; SoftWIRE by MeasurementComputing; WiT by DALSA Coreco; VEE Pro or SystemVue by Agilent; VisionProgram Manager from PPT Vision; Khoros from Khoral Research; Gedae byGedae, Inc.; Scicos from (INRIA); Virtuoso from Cadence; Rational Rosefrom IBM; Rhopsody or Tau from Telelogic; Ptolemy from the University ofCalifornia at Berkeley; or aspects of a Unified Modeling Language (UML)or SysML environment.

FIG. 5 depicts an exemplary TCE 510, which includes an editor 540, anexecution engine 550, a model 560, and an interface 570. Otherembodiments of a TCE may contain, for example, more components or fewercomponents than the components illustrated in FIG. 5. Moreover, in otherembodiments of a TCE, routines performed by the various componentscontained in TCE may be distributed among the components differentlythan described herein and shown in FIG. 5.

Editor 540 may support receiving instructions through user interface 408on behalf of a user (e.g., textual code received from a keyboard).Editor 540 may further support editing code (e.g., source code),requirements, and/or tests that may be generated from or otherwiseassociated with model 560. In an embodiment, editor 540 may be a blockdiagram editor that allows a user to, for example, specify, edit,annotate, save, publish, and/or print the model 560. For example, ablock diagram of model 560 may be presented (e.g., displayed) and theeditor 540 may contain one or more provisions for specifying, editing,annotating, saving, publishing, and/or printing the block diagram. Inanother embodiment, editor 540 may provide a user interface that allowsa user to make use of scripts that can include first routines compatiblewith an informal interface and second routines compatible with a formalinterface. A script may be a collection of routines that are sequencedand editor 540 may allow first routines and second routines to be usedinterchangeably within the user interface or script.

Execution engine 550 may use model 560 to simulate some or all of thesystem represented by model 560. The simulation may include performingvarious computations, associated with the system, based on information(e.g., geometry information) associated with one or more textual orgraphical modeling elements contained in model 560. The computations mayinclude, but are not limited to, computations of dynamics, statics,equilibrium, mass, inertia, collision detection, collision response,and/or force fields associated with the system.

Model 560 may be, for example, a textual-model or a graphical model.Model 560 may include, but is not limited to, a time-based graphicalblock diagram model, a state transition diagram, a discrete event model,an activity diagram, a Unified Modeling Language (UML) diagram, asequence diagram, an entity flow network and a data flow model. Model560 may represent a system, such as a physical system. The systemrepresented by model 560 may be dynamic, linear, non-linear, acombination of these or some other type of system. The model 560 mayhave executable semantics and/or may be executable.

A time based block diagram may consist, for example, of blocks (e.g.,the subsystem blocks described herein) connected to one another (e.g.,via connector lines). The blocks may consist of elemental dynamicsystems such as a differential equation system (e.g., to specifycontinuous-time behavior), a difference equation system (e.g., tospecify discrete-time behavior), an algebraic equation system (e.g., tospecify constraints), a state transition system (e.g., to specify finitestate machine behavior), an event based system (e.g., to specifydiscrete event behavior), etc. The lines may represent signals (e.g., tospecify input/output relations between blocks or to specify executiondependencies between blocks), variables (e.g., to specify informationshared between blocks), physical connections (e.g., to specifyelectrical wires, pipes with volume flow, rigid mechanical connections,etc.), etc. The attributes may consist of meta information such assample times, dimensions, complexity (whether there is an imaginarycomponent to a value), data type, etc. associated with the modelelements.

In a time based block diagram, ports may be associated with blocks. Arelationship between two ports may be created by connecting a line(e.g., a connector line) between the two ports. Lines may be connectedto other lines, for example by creating branch points. For instance,three or more ports can be connected by connecting a line to each of theports, and by connecting each of the lines to a common branch point forall of the lines. A common branch point for the lines that representphysical connections may be a dynamic system (e.g., by summing allvariables of a certain type to zero or by equating all variables of acertain type). A port may be an input port, an output port, an enableport, a trigger port, a function-call port, a publish port, a subscribeport, an exception port, an error port, a physics port, an entity flowport, a data flow port, a control flow port, etc.

Relationships between blocks may be causal and/or non-causal. Forexample, a model may include a block that represents a continuous-timeintegration block that may be causally related to a data logging blockby using a line (e.g., a connector line) to connect an output port ofthe continuous-time integration block to an input port of the datalogging block. Further, during execution of the model, the value storedby the continuous-time integrator may change as the current time of theexecution progresses. The value of the state of the continuous-timeintegrator may be available on the output port and the connection withthe input port of the data logging block may make this value availableto the data logging block.

A sample time may be associated with the elements of a graphical model.For example, a graphical model may include a block with a continuoussample time such as a continuous-time integration block that mayintegrate an input value as time of execution progresses. Thisintegration may be specified by a differential equation. Duringexecution the continuous-time behavior may be approximated by anumerical integration scheme that is part of a numerical solver. Thenumerical solver may take discrete steps to advance the execution time,and these discrete steps may be constant during an execution (e.g.,fixed step integration) or may be variable during an execution (e.g.,variable-step integration).

Alternatively, or additionally, a graphical model may include a blockwith a discrete sample time such as a unit delay block that may outputvalues of a corresponding input after a specific delay. This delay maybe a time interval and this interval may determine a sample time of theblock. During execution, the unit delay block may be evaluated each timethe execution time has reached a point in time where an output of theunit delay block may change. These points in time may be staticallydetermined based on a scheduling analysis of the graphical model beforestarting execution.

Alternatively, or additionally, a graphical model may include a blockwith an asynchronous sample time, such as a function-call generatorblock that may schedule a connected block to be evaluated at anon-periodic time. During execution, a function-call generator block mayevaluate an input and when the input attains a specific value when theexecution time has reached a point in time, the function-call generatorblock may schedule a connected block to be evaluated at this point intime and before advancing execution time.

Further, the values of attributes of a graphical model may be inferredfrom other elements of the graphical model or attributes of thegraphical model. For example, the graphical model may include a block,such as a unit delay block, that may have an attribute that specifies asample time of the block. When a graphical model has an executionattribute that specifies a fundamental execution period, the sample timeof the unit delay block may be inferred from this fundamental executionperiod.

As another example, the graphical model may include two unit delayblocks (e.g., blocks 430) where the output of the first of the two unitdelay blocks is connected to the input of the second of the two unitdelay block. The sample time of the first unit delay block may beinferred from the sample time of the second unit delay block. Thisinference may be performed by propagation of model element attributessuch that after evaluating the sample time attribute of the second unitdelay block, a graph search proceeds by evaluating the sample timeattribute of the first unit delay block since it is directly connectedto the second unit delay block.

The values of attributes of a graphical model may be set tocharacteristics settings, such as one or more inherited settings, one ormore default settings, etc. For example, the data type of a variablethat is associated with a block may be set to a default such as adouble. Because of the default setting, an alternate data type (e.g., asingle, an integer, a fixed point, etc.) may be inferred based onattributes of elements that the graphical model comprises (e.g., thedata type of a variable associated with a connected block) and/orattributes of the graphical model. As another example, the sample timeof a block may be set to be inherited. In case of an inherited sampletime, a specific sample time may be inferred based on attributes ofelements that the graphical model comprises and/or attributes of thegraphical model (e.g., a fundamental execution period).

The described embodiments may also include a code generator forgenerating code from a model. In an embodiment, the code generator mayanalyze a model generated by the described graphical modeling tool andproduce code that corresponds to the model. In an embodiment, codegenerator can generate source code, assembly language code, binary code,interface information, configuration information, performanceinformation, etc., from all or a portion of a graphical model. Forexample, the code generator can generate C, C++, SystemC, Java, etc.,from the graphical model. Embodiments of code generator can furthergenerate Unified Modeling Language (UML) based representations and/orextensions from some or all of a graphical model (e.g., System ModelingLanguage (SysML), Extensible Markup Language (XML), Modeling andAnalysis of Real Time and Embedded Systems (MARTE), Hardware DescriptionLanguage (HDL, VHDL, Verilog, et al.), Automotive Open SystemArchitecture (AUTOSAR), etc.).

In a hierarchical state transition diagram (e.g., MathWorks Stateflowenvironment), a particular state may have one or more substates. Each ofthese substates may have a certain integrity level that is based on thesuperstate (or superstates) associated with the substates. Similarly,the superstate (or superstates) may have a certain integrity level basedon one or more of the substates below the superstate (or superstates).

The described integrity level relationship between superstates andsubstates may be extended generally to any hierarchical structure, suchthat integrity levels of one hierarchical level is determined fromanother hierarchical level.

Similarly, the described integrity level relationship betweensuperstates and substates may be extended generally to textual languages(e.g., “C”, “C++”, MATLAB, et al.). For example, a function call madewithin a textual language may have more function calls nested withinthat function call (i.e., sub-function calls within the main functioncall). An integrity level relationship may therefore exist between thesub-function calls and the main function call, or between the mainprogram and the called programs.

In some embodiments, a subsystem block may be designated as“trustworthy,” which means that the subsystem block and all of thecomponents within the subsystem block have been verified as reliable andso may be excluded from an integrity level analysis. Such a trustedassembly may be deemed to have a predetermined integrity level for thepurpose of analyzing other subsystem blocks in the system. No time orcomputing resources needs to be dedicated to analyzing the componentswithin the trusted assembly. The trusted assembly may have beenevaluated at a time prior to the analysis of the subsystem block inwhich the trusted assembly is a component. The use of a trusted assemblymay expedite the analysis of the overall system.

In some embodiments, the code generator may generate code for onlycertain portions of the graphical model. For example, in one embodimentthe code generator may generate code only for portions of the graphicalmodel characterized by a particular integrity level, above a certainintegrity level threshold or below a certain integrity level threshold.

FIG. 6 illustrates one of the described embodiments in which subsystemblocks of a graphical model are evaluated to reduce or preventinterference between the blocks. Step 602 marks the beginning of theevaluation. At step 604, an integrity level is obtained for a firstsubsystem block of the model. The integrity level describes the extentto which the subsystem block is critical to the system. At step 608, anintegrity level property is assigned to at least one of the input ports(inports) of this first subsystem block. The integrity level property isbased on the integrity level of the first subsystem block.

At step 606, an integrity level is obtained corresponding to a secondsubsystem block of the model. At step 610, an integrity level propertyis assigned to at least one of the output ports (outports) of the secondsubsystem block. The integrity level property is based on the integritylevel of the second subsystem block.

At step 612, the integrity level property of at least one inport/outportpair is evaluated to determine whether the connection of theinport-to-outport pair is inappropriate. An inport/outport pair is asecond subsystem output connected to first subsystem input.

Step 614 represents the result of the evaluation of step 612. When theevaluation indicates that an inappropriate connection exists, a firstaction is performed as in step 616. When the evaluation indicates thatthe connection is not inappropriate, a section action is performed asshown in step 618. After either the first or second action is performed,the evaluation is complete as shown in step 620.

FIG. 7 illustrates another of the described embodiments in whichhierarchical blocks of a graphical model are evaluated to reduce orprevent interference between the blocks. Step 702 designates thebeginning of the evaluation. At step 704, an integrity level is obtainedfor a first hierarchical block of the model. At step 706, an integritylevel is obtained for a second hierarchical block of the model. At step708 the integrity level property of at least one inport/outport pair isevaluated to determine whether the connection of the inport-to-outportpair is inappropriate. After the inport/outport pair evaluation iscomplete, the integrity level evaluation is finished as shown in step710.

The described embodiments may evaluate the hierarchical structure ofsubsystem components (or other hierarchical structures) to determinewhich subsystem components (one or more) or subsystem blocks (one ormore), if their integrity levels were increased, would have amultiplicative impact (e.g., the greatest impact) achieving appropriateconnections. For example, increasing the integrity level of onesubsystem block with outports that are connected to inports of a numberof other subsystem blocks may increase the integrity level of some orall of these other subsystem blocks. This measure of sensitivity tointegrity variations may be used, for example, to aid a user inoptimizing a system design with respect to overall integrity.

Further, the described embodiments may include a “Model Advisor” foranalyzing a set of subsystem components or subsystem blocks to determinewhich subsystem components or subsystem blocks are candidates forimplementing an increased integrity value. Adding redundancy may be oneway to increase the integrity of a subsystem block. The measure ofintegrity evaluation described herein may be used for this analysis.

The described embodiments may evaluate the hierarchical structure ofsubsystem components (or other hierarchical structures) to determinewhich subsystem component (one or more) or subsystem blocks (one ormore), if their integrity levels were decreased, would have less (e.g.,the least) impact on achieving appropriate connections than decreasingthe integrity level of other subsystem components or subsystem blocks.This measure of sensitivity to integrity variations may be used, forexample, to aid a user in determining which subsystem component orsubsystem block could have a reduced integrity value with little or noeffect on other subsystems within a system.

The “Model Advisor” described herein may be used for analyzing a set ofsubsystem components or subsystem blocks to determine which subsystemcomponents or subsystem blocks are candidates for implementing adecreased integrity value. The measure of integrity evaluation describedherein may be used for this analysis.

The described embodiments are not limited to an implementation that iscontained within a single platform. The described embodiments may alsobe suitable for use in a distributed computing environment or in anenvironment of computing devices communicating through a network orother linked architecture. For example, a first computer system may beused to evaluate one or more subsystem blocks, while a second computersystem may be used to evaluate one or more other subsystem blocks.

In some embodiments, subsystem blocks may be assigned to differentgroups. In this configuration, subsystem blocks from one group may beprocessed independently from subsystem blocks in other groups.

The foregoing description of embodiments is intended to provideillustration and description, but is not intended to be exhaustive or tolimit the invention to the precise form disclosed. Modifications andvariations are possible in light of the above teachings or may beacquired from a practice of the invention. Further, non-dependent actsmay be performed in parallel. Also, the term “user”, as used herein, isintended to be broadly interpreted to include, for example, a computingdevice (e.g., a workstation) or a user of a computing device, unlessotherwise stated. The term “designer” may be used herein in place of“user.”

It will be apparent that one or more embodiments, described herein, maybe implemented in many different forms of software and hardware.Software code and/or specialized hardware used to implement embodimentsdescribed herein is not limiting of the invention. Thus, the operationand behavior of embodiments were described without reference to thespecific software code and/or specialized hardware—it being understoodthat one would be able to design software and/or hardware to implementthe embodiments based on the description herein.

Further, certain embodiments of the invention may be implemented aslogic that performs one or more functions. This logic may behardware-based, software-based, or a combination of hardware-based andsoftware-based. Some or all of the logic may be stored on one or moretangible computer-readable storage media 406 and may includecomputer-executable instructions that may be executed by a processor,such as processor 404. The computer-executable instructions may includeinstructions that implement one or more embodiments of the invention.The tangible computer-readable storage media 406 may be volatile ornon-volatile and may include, for example, flash memories, dynamicmemories, removable disks, and non-removable disks.

No element, act, or instruction used herein should be construed ascritical or essential to the invention unless explicitly described assuch. Also, as used herein, the article “a” is intended to include oneor more items. Where only one item is intended, the term “one” orsimilar language is used. Further, the phrase “based on” is intended tomean “based, at least in part, on” unless explicitly stated otherwise.

It is intended that the invention not be limited to the particularembodiments disclosed above, but that the invention will include any andall particular embodiments and equivalents falling within the scope ofthe following appended claims.

1. (canceled)
 2. A non-transitory computer-readable storage mediumcomprising computer-executable instructions that, when executed by atleast one processor, cause the at least one processor to: provide a userinterface to generate a computerized graphical model representing asystem, the graphical model including a plurality of subsystem blocksand a connection between a first subsystem block and at least one othersubsystem block of the plurality of subsystem blocks; obtain anintegrity level of the first subsystem block and an integrity levelassociated with the at least one other subsystem block; evaluate apredicted impact on an overall integrity level of the graphical modelfrom a change to the integrity level of the first subsystem block,wherein the evaluation is based on the integrity level associated withthe at least one other subsystem block; and determine whether to changethe integrity level of the first subsystem block based on the result ofthe evaluation.
 3. The non-transitory computer-readable storage mediumof claim 2, wherein the instructions are further configured such thatthe at least one processor changes the integrity level of the firstsubsystem block when the changing produces a greater increase in theoverall integrity level than increasing the integrity level associatedwith one or more of the at least one other subsystem block.
 4. Thenon-transitory computer-readable storage medium of claim 3, whereinincreasing the integrity level of the first subsystem block includesadding redundancy.
 5. The non-transitory computer-readable storagemedium of claim 2, wherein the instructions are further configured suchthat the at least one processor decreases the integrity level of thefirst subsystem block in response to determining that decreasing theintegrity level of the first subsystem block will not change the overallintegrity level.
 6. The non-transitory computer-readable storage mediumof claim 2, wherein the instructions are further configured such thatthe at least one processor determines whether decreasing the integritylevel of the first subsystem block will violate a rule that the firstsubsystem block cannot connect to a subsystem block with a higherintegrity level.
 7. The non-transitory computer-readable storage mediumof claim 2, wherein the determination further determines whetherdecreasing the integrity level of the first subsystem block will affectan inferred integrity level of the at least one other subsystem block.8. The non-transitory computer-readable storage medium of claim 2,wherein obtaining an integrity level associated with the first subsystemblock and the at least one other subsystem block includes inferring theone or more integrity levels from at least one of: an input to one ofthe first subsystem block and the at least one other subsystem block; anoutput from the first subsystem block and the at least one othersubsystem block; and one or more connections linking the first subsystemblock and the at least one other subsystem block.
 9. The non-transitorycomputer-readable storage medium of claim 2, wherein at least one of theplurality of subsystem blocks is a hierarchical subsystem blockcontaining other subsystem blocks.
 10. A computerized method comprising:providing a user interface to generate a graphical model representing asystem, the graphical model including a plurality of subsystem blocksand a connection between a first subsystem block and at least one othersubsystem block of the plurality of subsystem blocks; obtaining anintegrity level of the first sub system block and an integrity levelassociated with the at least one other subsystem block; evaluating apredicted impact on an overall integrity level of the graphical modelfrom a change to the integrity level of the first subsystem block,wherein the evaluation is based on the integrity level associated withthe at least one other subsystem block; and determining whether tochange the integrity level of the first subsystem block as a function ofthe result of the evaluation.
 11. The method of claim 10, whereindetermining further includes changing the integrity level of the firstsubsystem block when the changing produces a greater increase in theoverall integrity level than increasing the integrity level associatedwith one or more of the at least one other subsystem block.
 12. Themethod of claim 11, wherein increasing the integrity level of the firstsubsystem block includes adding redundancy.
 13. The method of claim 10,further comprising decreasing the integrity level of the first subsystemblock in response to determining that decreasing the integrity level ofthe first subsystem block will not change the overall integrity level.14. The method of claim 10, further comprising determining whetherdecreasing the integrity level of the first subsystem block will violatea rule that the first subsystem block cannot connect to a subsystemblock with a higher integrity level.
 15. The method of claim 10, furthercomprising determining whether decreasing the integrity level of thefirst subsystem block will affect an inferred integrity level of the atleast one other subsystem block.
 16. A non-transitory computer-readablestorage medium comprising computer-executable instructions that, whenexecuted by at least one processor, cause the at least one processor to:provide a user interface to generate a computerized graphical modelrepresenting a system, the graphical model including a plurality ofsubsystem blocks; obtain one or more integrity levels associated with atleast some of the plurality of subsystem blocks; determine whether afirst and a second subsystem block of the plurality of subsystem blocksinterfere with each other; and when the first and the second subsystemblocks do not interfere with each other, execute the first and thesecond subsystem blocks in parallel.
 17. The non-transitorycomputer-readable storage medium of claim 16 wherein the at least oneprocessor determines whether the first and the second subsystem blocksinterfere with each other based on integrity levels associated with thefirst and second subsystem blocks.
 18. The non-transitorycomputer-readable medium of claim 16, wherein the first and secondsubsystem blocks interfere with each other when a connectiontherebetween violates a rule that a subsystem block with higherintegrity cannot have its computational behavior influenced by asubsystem block of lower integrity.
 19. The non-transitorycomputer-readable storage media of claim 16, wherein one or moresubsystem blocks in the graphical model is a hierarchical subsystemblock containing other subsystem blocks.